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Access control systems must be evaluated in part on how well they 
enable one to distribute the access rights needed for cooperation, 
while simultaneously limiting the propagation of rights which 
would create vulnerabilities. Analysis to date implicitly assumes 
access is controlled only by manipulating a system's protection 
state-the arrangement of the access graph. Because of the 
limitations of this analysis, capability systems have been "proven" 
unable to enforce some basic policies: revocation, confinement, and 
the * -properties (explained in the text). 

In actual practice, programmers build access abstractions -programs 
that help control access, extending the kinds of access control that 
can be expressed. Working in Dennis and van Horn's original 
capability model, we show how abstractions were used in actual 
capability systems to enforce the above policies. These simple, 
often tractable programs limited the rights of arbitrarily complex, 
untrusted programs. When analysis includes the possibility of 
access abstractions, as it must, the original capability model is 
shown to be stronger than is commonly supposed. 
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Abstract. Access control systems must be evaluated in part on how well 
they enable one to distribute the access rights needed for cooperation, while 
simultaneously limiting the propagation of rights which would create vul- 
nerabilities. Analysis to date implicitly assumes access is controlled only by 
manipulating a system's protection state — the arrangement of the access 
graph. Because of the limitations of this analysis, capability systems have 
been "proven" unable to enforce some basic policies: revocation, confine- 
ment, and the * -properties (explained in the text). 

In actual practice, programmers build access abstractions — programs that 
help control access, extending the kinds of access control that can be ex- 
pressed. Working in Dennis and van Horn's original capability model, we 
show how abstractions were used in actual capability systems to enforce the 
above policies. These simple, often tractable programs limited the rights of 
arbitrarily complex, untrusted programs. When analysis includes the possi- 
bility of access abstractions, as it must, the original capability model is 
shown to be stronger than is commonly supposed. 

1. Introduction 

We live in a world of insecure computing. Viruses regularly roam our networks causing 
damage. By exploiting a single bug in an ordinary server or application, an attacker may 
compromise a whole system. Bugs tend to grow with code size, so vulnerability usually 
increases over the life of a given software system. Lacking a readily available solution, 
users have turned to the perpetual stopgaps of virus checkers and firewalls. These stop- 
gaps cannot solve the problem — they provide the defender no fundamental advantage over 
the attacker. 

In large measure, these problems are failures of access control. All widely-deployed op 
erating systems today — including Windows, UNIX variants, Macintosh, and PalmOS — 
routinely allow programs to execute with excessive and largely unnecessary authority. For 
example, when you run Solitaire, it needs only to render into its window, receive UI 
events, and perhaps save a game state to a file you specify. Under the Principle of Least 
Authority (POLA — closely related to the Principle of Least Privilege [Saltzer75]), it 
would be limited to exactly these rights. Instead, today, it runs with all of your authority. It 



can scan your email for interesting tidbits and sell them on eBay to the highest bidder; all 
the while playing only within the rules of your system. Because applications are run with 
such excessive authority, they serve as powerful platforms from which viruses and human 
attackers penetrate systems and compromise data. The flaws exploited are not bugs in the 
usual sense. Each operating system is functioning as specified, and each specification is a 
valid embodiment of its access control paradigm. The flaws lie in the access control 
paradigm. 

By access control paradigm we mean an access control model plus a way of thinking — 
a sense of what the model means, or could mean, to its practitioners, and of how its ele- 
ments should be used. 

For purposes of analysis, we pick a frame of reference — a boundary between a base 
system (e.g., a "kernel" or "TCB") creating the rules of permissible action, and programs 
running on that base, able to act only in permitted ways. In this paper, "program" refers 
only to programs running on the base, whose access is controlled by its rules. 

Whether to enable cooperation or to limit vulnerability, we care about authority rather 
than permissions. Permissions determine what actions an individual program may perform 
on objects it can directly access. Authority describes effects a program may cause on ob- 
jects it can access, either directly by permission, or indirectly by permitted interactions 
with other programs. To understand authority, we must reason about the interaction ofpro- 
gram behavior and the arrangement of permissions. While Dennis and van Horn's 1966 pa- 
per, Programming Semantics for Multiprogrammed Computations [Dennis66] clearly sug- 
gested both the need and a basis for a unified semantic view of permissions and program 
behavior, we are unaware of any formal analysis pursuing this approach in the security, 
programming language, or operating system literature. 

Over the last 30 years, the formal security literature has reasoned about bounds on au 
thority exclusively from the evolution of state in protection graphs — the arrangement of 
permissions. This implicitly assumes all programs are hostile. While conservatively safe, 
this approach omits consideration of security enforcing programs. Like the access it con- 
trols, security policy emerges from the interaction between the behavior of programs and 
the underlying protection primitives. This omission has resulted in false negatives — mis- 
taken infeasibility results — diverting attention from the possibility that an effective access 
control model has existed for 37 years. 

In this paper, we offer a new look at the original capability model proposed by Dennis 
and van Horn [Dennis66] — here called object-capabilities. Our emphasis — which was also 
their emphasis — is on expressing policy by using abstraction to extend the expressiveness 
of object-capabilities. Using abstraction, object-capability practitioners have solved prob- 
lems like revocation (withdrawing previously granted rights), overt confinement (coopera- 
tively isolating an untrusted subsystem), 1 and the *-properties (enabling one-way commu- 
nication between clearance levels). We show the logic of these solutions, using only func- 
tionality available in Dennis and van Horn's 1966 Supervisor, hereafter referred to as 



1 Semantic models, specifications, and correct programs deal only in overt causation. 
Since this paper examines only models, not implementations, we ignore covert and side 
channels. In this paper, except where noted, the "overt" qualifier should be assumed. 



"DVH." In the process, we show that many policies that have been "proven" impossible 
are in fact straightforward. 

The balance of this paper proceeds as follows. In "Terminology and Distinctions", we 
explain our distinction between permission and authority. In "How Much Authority Does 
'cp' Need?", we use a pair of Unix shell examples to contrast two paradigms of access 
control. In "The Object-Capability Paradigm", we explain the relationship between the ob- 
ject-capability paradigm and the object paradigm. We introduce the object-capability lan 
guage E, which we use to show access control abstractions. In "Confinement", we show 
how object-capability systems confine programs rather than uncontrolled subjects. We 
show how confinement enables a further pattern of abstraction, which we use to implement 
the *-properties. 




2. Terminology and Distinctions 

A direct access right to an object gives a 
subject permission to invoke the behav- 
ior of that object. Here, Alice has direct 
access to /etc/passwd, so she has per- / 

mission to invoke any of its operations, subject direct access right access 
She accesses the object, invoking its client permission invocation provider 
read() operation. Fig 1- Access diagrams depict protection state. 

By subject we mean the finest-grain 
unit of computation on a given system that may be given distinct direct access rights. De- 
pending on the system, this could be anything from: all processes run by a given user ac- 
count, all processes running a given program, an individual process, all instances of a giv 
en class, or an individual instance. To encourage anthropomorphism we use human names 
for subjects. 

By object, we mean the finest-grain unit to which separate direct access rights may be 
provided, such as a file, a memory page, or another subject, depending on the system. 
Without loss of generality, we model restricted access to an object, such as read-only ac- 
cess to /etc/passwd, as simple access to another object whose behavior embodies the re- 
striction, such as access to the read-only facet of /etc/passwd which responds only to 
queries. 

Any discussion of access must carefully distinguish between permission and authority 
(adapted from Bishop and Snyder's distinction between de jure and de facto transfer 
[Bishop79]). Alice can directly read /etc/passwd by calling read(...) when the system's 
protection state says she has adequate permission. Bob (unshown), who does not have per- 
mission, can indirectly read /etc/passwd so long as Alice sends him copies of the text. 
When Alice and Bob arrange this relying only on the "legal" overt rules of the system, we 
say Alice is providing Bob with an indirect access right to read /etc/passwd, that she is 
acting as his proxy, and that Bob thereby has authority to read it. Bob's authority derives 
from the arrangement of permissions (Alice's read permission, Alice's permission to talk 
to Bob), and from the behavior of subjects and objects on permitted causal pathways (At 



ice's proxying behavior). The thin black arrows in our access diagrams depict permissions. 
We will explain the resulting authority relationships in the text. 

The protection state of a system is the arrangement of permissions at some instant in 
time, i.e., the topology of the access graph. Whether Bob currently has permission to ac- 
cess /etc/passwd depends only on the current arrangements of permissions. Whether 
Bob eventually gains permission depends on this arrangement and on the state and behav- 
ior of all subjects and objects that might cause Bob to be granted permission. We cannot 
generally predict if Bob will gain this permission, but a conservative bound can give us a 
reliable "no" or "maybe". 

From a given system's update rules — rules governing permission to alter permissions — 
one might be able to calculate a bound on possible future arrangements by reasoning only 
from the current arrangement. 2 This corresponds to Bishop and Snyder's potential de jure 
analysis, and gives us an arrangement-only bound on permission. With more knowledge, 
one can set tighter bounds. By taking the state and behavior of some subjects and objects 
into account, we may calculate a tighter partially behavioral bound on permission. 

Bob's eventual authority to /etc/passwd depends on the arrangement of permissions, 
and on the state and behavior of all subjects and objects on permitted causal pathways be- 
tween Bob and /etc/passwd. One can derive a bound on possible overt causality by rea- 
soning only from the current arrangement of permissions. This corresponds to Bishop and 
Snyder's potential de facto analysis, and gives us an arrangement-only bound on authori- 
ty. Likewise, by taking some state and behavior into account, we may calculate a tighter 
partially behavioral bound on authority. 

Systems have many levels of abstraction. At any moment our frame of reference is a 
boundary between a base system that creates rules and the subjects hosted on that base, re- 
stricted to play by those rules. By definition, abase system manipulates only permissions. 
Subjects extend the expressiveness of a base system by building abstractions whose behav- 
ior further limits the authority it provides to others. Taking this behavior into account, one 
can calculate usefully tighter bounds on authority. As our description ascends levels of ab- 
straction [Neumann80], the authority manipulated by the extensions of one level becomes 
the permissions manipulated by the primitives of the next higher base. Permission is rela- 
tive to a frame of reference. Authority is invariant. 

It is unclear whether Saltzer and Schroeder's Principle of Least Privilege is best inter- 
preted as least permission or least authority. As we will see, there is an enormous differ- 
ence between the two. 



2 The Harrison Ruzzo Ullman paper [Harrison76] is often misunderstood to say this cal- 
culation is never decidable. HRU actually says it is possible (indeed, depressingly easy) 
to design a set of update rules which are undecidable. At least three protection systems 
have been shown to be decidably safe [Jones76, ShapiroOO, MotwaniOO] . 



3. 



How Much Authority Does "c P " Need? 



Consider how the following Unix shell command works: 

$ cp foo.txt bar.txt 

Here, your shell passes to the cp program the two strings "foo.txt" and "bar.txt". 
By these strings, you mean particular files in your file system — your namespace of files. In 
order for cp to open the files you name, it must use your namespace, and it must be able to 
read and write any file you might name that you can read and write. Not only does cp op- 
erate with all your authority, it must. Given this way of using names, cp's least authority 
still includes all of your authority to the file system. So long as we normally install and run 
applications in this manner, both security and reliability are hopeless. 

By contrast, consider: 

$ cat < foo.txt > bar.txt 

This shell command brings about the same end effect. Although cat also runs with all 
your authority, for this example at least, it does not need to. As with function calls in any 
lexically scoped language (even FORTRAN), the names used to designate arguments are 
evaluated in the caller's namespace prior to the call (here, by opening files). The callee 
gets direct access to the first-class anonymous objects passed in, and designates them with 
parameter "names" bound in its own private name space (here, file descriptor numbers). 
The file descriptors are granted only to this individual process, so only this process can 
use these file descriptors to access these files. In this case, the two file descriptors passed 
in are all the authority cat needs to perform this request. 

Today's widely deployed systems use both styles of access control. They grant permis- 
sion to open a file on a per-account basis, creating the pools of authority on which viruses 
grow. These same systems flexibly grant access to a file descriptor on a per-process basis. 
Ironically, only their support of the first style is explained as their access control system. 
Object-capability systems differ from current systems more by the elimination of the first 
style than by the elaboration of the second. 

If support for the first style were eliminated and cat ran with access only to the file de- 
scriptors passed in, it could still do its job, and we could more easily reason about our vul- 
nerabilities to its malice or bugs. In our experience of object-capability programming, 
these radical reductions of authority and vulnerability mostly happen naturally. 

4. The Object-Capability Paradigm 

In the object model of computation [Goldberg76, Hewitt73], there is no distinction be- 
tween subjects and objects. A non-primitive object, or instance, is a combination of code 
and state, where state is a mutable collection of references to objects. The computational 
system is the dynamic reference graph of objects. Objects — behaving according to their 
code — interact by sending messages on references. Messages carry references as argu- 
ments, thereby changing the connectivity of the reference graph. 



The object-capability model uses the reference 
graph as the access graph, requiring that objects Matter tells s P ace how to curve - 
can interact only by sending messages on refer- S P ace tells matter how to move. 
ences. To get from objects to object-capabilities John Archibald Wheeler 

we need merely prohibit certain primitive abilities 

which are not part of the object model anyway, but which the object model by itself does- 
n't require us to prohibit — such as forged pointers, direct access to another's private state, 
and mutable static state [Kahn88, Rees96, MillerOO]. For example, C++, with its ability to 
cast integers into pointers, is still within the object model but not the object-capability 
model. Smalltalk and Java fall outside the object-capability model because their mutable 
static variables enable objects to interact outside the reference graph. 

Whereas the functionality of an object program depends only on the abilities provided 
by its underlying system, the security of an object-capability program depends on underly- 
ing inabilities as well. In a graph of mutually suspicious objects, one object's correctness 
depends not only on what the rules of the game say it can do, but also on what the rules 
say its potential adversaries cannot do. 

4.1. The Object-Capability Model 

The following model is an idealization of various object languages and object-capability 
operating systems. All its access control abilities are present in DVH (Dennis and van 
Horn's Supervisor) and most other object-capability systems. 3 Object-capability systems 
differ regarding concurrency control, storage management, equality, typing, and the primi- 
tiveness of messages, so we avoid these issues in our model. Our model does assume 
reusable references, so it may not fit object-capability systems based on concurrent 
logic/constraint programming [Miller87, Kahn88, Roy02]. However, our examples may 
easily be adapted to any object-capability system despite these differences. 
The static state of the reference graph is composed of the following elements. 

♦ An object is either a primitive or an instance. Later, we explain three kinds of 
primitives: data, devices, and a loader. Data is immutable. 

♦ An instance is a combination of code and state. We say it is an instance of the be- 
havior described by its code. For example, we say an operating system process is 
an instance of its program. 

♦ An instance's state is a mutable map from indexes to references. 

♦ A reference provides access to an object, indivisibly combining designation of the 
object, the permission to access it, and the means to access it. The permission ar- 
rows on our access diagrams now depict references. 

♦ A capability is a reference to non-data. 



Our object-capability model is essentially the untyped lambda calculus with applicative- 
order local side effects and a restricted form of eval — the model Actors and Scheme 
are based on. This correspondence of objects, lambda calculus, and capabilities was no 
ticed several times by 1973 [Goldberg76, Hewitt73, Morris73], and investigated 
explicitly in [Tribble95, Rees96]. 



Model Term 


Capability OS Terms 


Object Language Terms 


instance 


process, domain 


instance, closure 


code 


non-kernel program 
+ literal data 


lambda expression, 
class file, method table 


state 


address space + c-list 


environment, 




(capability list) 


instance variable frame 


index 


virtual memory address, 


lexical name, variable offset, 




c-list index 


argument position 


loader 


domain creator, exec 


eval, ClassLoader 



Table 1: Object / Capability Corresponding Concepts 



♦ Code is some form of data (such as instructions) used to describe an instance's be- 
havior to a loader, as explained below. Code also contains literal data. 

♦ Code describes how a receiving instance (or "self) reacts to an incoming mes- 
sage. 

♦ While an instance is reacting, its addressable references are those in the incoming 
message, in the receiving instance's state, and in the literal data of the receiving 
instance's code. The directly accessible objects are those designated by address- 
able references. 

♦ An index is some form of data used by code to indicate which addressable refer- 
ence to use, or where in the receiving instance's state to store an addressable refer- 
ence. Depending on the system, an index into state may be an instance variable 
name or offset, a virtual memory address, or a capability-list index (a c-list index, 
like a file descriptor number). An index into a message may be an argument posi- 
tion, argument keyword, or parameter name. 

Message passing and object creation dynami- Alice says: bob.foo(carol) 

cally change the graph's connectivity. 

In the initial conditions of Figure 2, Bob and 
Carol are directly accessible to Alice. When Al- 
ice sends Bob the message "foo (carol) ", she is 
both accessing Bob and permitting Bob to access 
Carol. 

Alice can cause effects on the world outside Fi § 2: Introduction by Message Passing 
herself only by sending messages to objects directly accessible to her (Bob), where she 
may include, at distinct argument indexes, references to objects directly accessible to her 
(Carol). We model a call-return pattern as two messages. For example, Alice gains infor- 
mation from Bob by causing Bob (with a query) to cause her to be informed (with a re- 
turn). 

Bob is affected by the world outside himself only by the arrival of messages sent by 
those with access to him. On arrival, the arguments of the message (Carol) become direct 
ly accessible to Bob. Within the limits set by these rules, and by what Bob may feasibly 
know or compute, Bob reacts to an incoming message only according to his code. All 
computation happens only in reaction to messages. 




We distinguish three kinds of primitive objects. 

♦ Data objects, such as the number 3. Access to these are knowledge limited rather 
than permission limited. If Alice can figure out which integer she wants, whether 
3 or your private key, she can have it. Data provides only information, not access. 
Because data is immutable, we need not distinguish between a reference to data 
and the data itself. (In an OS context, we model user-mode compute instructions 
as data operations.) 

♦ Devices. For purposes of analysis we divide the world into a computational sys- 
tem containing all objects of potential interest, and an external world. On the 
boundary are primitive devices, causally connected to the external world by unex- 
plained means. A non-device object can only affect the external world by sending 
a message to an accessible output device. A non-device object can only be affect 
ed by the external world by receiving a message from an input device that has ac- 
cess to it. 

♦ A loader makes new instances. The creation request to a loader has two argu- 
ments: code describing the behavior of the new instance, and an index => refer- 
ence map providing all the instance's initial state. A loader must ensure (whether 
by code verification or hardware protection) that the instance's behavior cannot 
violate the rules of our model. A loader returns the only reference to the new in- 
stance. (Below, we use a loader to model nested lambda evaluation.) As a safe 
simplification of actual systems, this paper assumes a single, immutable, univer- 
sally accessible loader. 

By these rules, only connectivity begets connectivity — all access must derive from pre- 
vious access. Two disjoint subgraphs cannot become connected as no one can introduce 
them. Arrangement-based analysis of bounds on permission proceeds by graph reachabili- 
ty arguments. Overt causation, carried only by messages, flows only along permitted path 
ways, so we may again use reachability arguments to reason about bounds on authority 
and causality. The transparency of garbage collection relies on such arguments. 

The object-capability model recognizes the security properties latent in the object mod 
el. All the restrictions above are consistent with good object programming practice even 
when security is of no concern. 

4.2. A Taste of E 

To illustrate how the object-capability model is used to solve access control problems, we 
use a subset of the E language as our notation. This subset directly embodies our object- 
capability model. All the functionality it provides is present in DVH. Full/? extends the 
capability paradigm beyond the model presented above. Using a cryptographic capability 
protocol among mutually suspicious machines, E creates a distributed persistent reference 
graph, supporting decentralized access control with somewhat weaker properties than are 
possible within a single machine. These issues are beyond the scope of this paper. For the 
rest of this paper, "£"' refers to our subset of E. 

In E, an instance is a single-parameter closure instantiated by lambda evaluation. The 
single (implicit) parameter is for the incoming message. A message send applies an object- 



as-closure to a message-as-argument. E combines Scheme-like semantics [Kelsey98] with 
syntax for message sending, method dispatch, and soft type checking, explained below. 
Here is a simple data abstraction. 

def polntMaker { 

to make(x :int, y :int) :any { 
A def point { 

to getX() :int { A x } 
to getY() :int { A y } 
to add (otherPt) :any { 

A pointMaker .make (x . add (otherPt . getx ( ) ) , 
y . add ( otherPt . getY ( ) ) ) 

} } } } 

The expressions defining pointMaker and point are object definitions — both a lamb- 
da expression and a variable definition. An object definition evaluates to a closure whose 
behavior is described by its body, and it defines a variable (shown in bold italics) to hold 
this value. The body consists of to clauses defining methods, followed by an optional 
match clause as we will see later. Because an object is always applied to a message, the 
message parameter is implicit, as is the dispatch on the message name to select a method. 
The prefix " A " acts like the return keyword of many languages. The pointMaker has a 
single method, make, that defines and returns a new point. 

Method definitions (shown in bold) and variable definitions (shown in italics) can have 
an optional soft type declaration [Cartwright91], shown as a ":" followed by a guard ex- 
pression. A guard determines which values may pass. The any guard used above allows 
any value to pass as is. 

The nested definition of point uses x and y freely. These are its instance variables, and 
together form its state. The state maps from indexes "x" and "y" to the associated values 
from point's creation context. 

Using the loader described above, we can transform the above code to 

def pointMaker { 

to make(x :int, y :int) :any { 

A def point := loader . load ("def point {...}", 

["x" => x, "y" => y] ) 

} } 

Rather than a source string, a realistic loader would accept some form of separately 
compiled code. 

The expression ["x" => x, "y" => y] builds a map of index => reference associa- 
tions. All "linking" happens only by virtue of these associations — only connectivity begets 
connectivity. 

Applying this transformation recursively would unnest all object definitions. Nested ob- 
ject definitions better explain instantiation in object languages. The loader better ex- 



plains process or domain creation in operating systems. In E, we almost always use object 
definitions, but we use the loader below to achieve confinement. 



4.3. Revocation: Redell's 1974 Caretaker Pattern 

When Alice says bob . foo (carol) , she Capability systems modeled as unforge- 
gives Bob unconditional, full, and perpetual able references present the other ex- 
access to Carol. Given the purpose of Alice's treme, where delegation is trivial, and 
message to Bob, such access may dangerous- revocation is infeasible. 
ly exceed least authority. In order to practice — Chander, Dean, Mitchell 

POLA, Alice might need to somehow restrict [ChanderOl] 
the rights she grants to Bob. For example, 

she might want to ensure she can revoke access at a later time. But in a capability system, 
capabilities themselves are the only representation of permission, and they provide only 
unconditional, full, perpetual access to the objects they designate. 

What is Alice to do? She can use (a slight simplification of) Redell's Caretaker pattern 
for revoking access [Redell74], shown here using additional elements ofE we explain be- 
low. 

def caretakerMaker { 

to make ( var target) :any { 
def caretaker { 

match [verb : String, args : any [ ] ] { 
E . call (target, verb, args) 

} } 

def revoker { 

to revoke () :void { 
target := null 

} } 

A [caretaker, revoker] 

} } 

Instead of saying "bob . foo (carol) ", Alice can instead say: 

def [carol2, carol2Rvkr] := caretakerMaker .make (carol) 
bob. foo (carol2) 

The Caretaker carol2 transparently forwards messages it receives to target's current 
value. The Revoker carol2Rvkr changes what that current value is. Alice can later re- 
voke the effect of her grant to Bob by saying "carol2Rvkr . revoke ( ) ". 

Variables in E are non-assignable by default. The var keyword means target can be 
assigned, ( var is the opposite of Java's final .) Within the scope of target's definition, 
make defines two objects, caretaker and revoker, and returns them to its caller in a two 
element list. Alice receives this pair, defines carol2 to be the new Caretaker, and defines 
carol2Rvkr to be the corresponding Revoker. Both objects use target freely, so they 




Fig 3: Revocable Access 



or Java's Proxy. Messages are sent 
much like Smalltalk's perform:, Java's "reflection", or 



both share access to the same assignable target 
variable (which is therefore a separate object). 

What happens when Bob invokes carol2, 
thinking he's invoking the kind of thing Carol 
is? An object definition contains methods and an 
optional match clause defining a matcher. If an 
incoming message (x.add(3)) doesn't match 
any of the methods, it is given to the matcher. 
The verb parameter is bound to the message 
name ("add") and the args to the argument list 
( [ 3 ] ). This allows messages to be received 
genetically without prior knowledge of their 
API, much like Smalltalk's doesNotUnderstand: 
generically using "e . call (...) ' 
Scheme's apply. 

This Caretaker 4 provides a temporal restriction of authority. Similar patterns provide 
other restrictions, such as filtering facets that let only certain messages through. Even in 
systems not designed to support access abstraction, many simple patterns happen natural 
ly. Under Unix, Alice might provide a filtering facet as a process reading a socket Bob can 
write. The facet process would access Carol using Alice's permissions. 

4.4. Analysis and Blind Spots 

Given Redell's existence proof in 1974, what are we to make of subsequent arguments that 
revocation is infeasible in capability systems? Of those who made this impossibility claim, 
as far as we are aware, none pointed to a flaw in Redell's reasoning. The key is the differ- 
ence between permission and authority analysis. ([ChanderOl] analyzes, in our terms, only 
permission.) By such an analysis, Bob was never given permission to access Carol, so 
there was no access to Carol to be revoked! Bob was given permission to access carol2, 
and he still has it. No permissions were revoked. 

A security officer investigating an incident needs to know who has access to a 
compromised object. 

— Karger and Herbert [Karger84] 

In their paper, Karger and Herbert propose to give a security officer a list of all subjects 
who are, in our terms, permitted to access Carol. This list will not include Bob's access to 
Carol, since this indirect access is represented only by the system's protection state taken 
together with the behavior of objects playing by the rules. Within their system, Alice, by 



4 The simple Caretaker shown here depends on Alice assuming that Carol will not provide 
Carol's clients with direct access to herself. 

See www.erights.org/elib/capability/deadman.html for a more general treatment of revo- 
cation in E. 



restricting the authority given to Bob as she should, has inadvertently thwarted the security 
officer's ability to get a meaningful answer to his query. 

To render a permission- only analysis useless, a threat model need not include either 
malice or accident; it need only include subjects following security best practices. 

An arrangement-only bound on permission or authority would include the possibility of 
the Caretaker giving Bob direct access to Carol — precisely what the Caretaker was con- 
structed not to do. Only by reasoning about behaviors can Alice see that the Caretaker is a 
"smart reference". Just as pointMaker extends our vocabulary of data types, raising the 
abstraction level at which we express solutions, so does the Caretaker extend our vocabu- 
lary for expressing access control. Alice (or her programmer) should use arrangement-only 
analysis for reasoning about what potential adversaries may do. But Alice also interacts 
with many objects, like the Caretaker, because she has some confidence she understands 
their actual behavior. 

4.5. Access Abstraction 

The object-capability model does not describe access control as a separate concern, to be 
bolted on to computation organized by other means. Rather it is a model of modular com 
putation with no separate access control mechanisms. All its support for access control is 
well enough motivated by the pursuit of abstraction and modularity. Parnas' principle of 
information hiding [Parnas72] in effect says our abstractions should hand out information 
only on a need to know basis. POLA simply adds that authority should be handed out only 
on a need to do basis [Crockford97]. Modularity and security each require both of these 
principles. 

The object-capability paradigm, in the air by 1967 [Wilkes79, Fabry 74], and well es- 
tablished by 1973 [Redell74, Hewitt73, Morris73, Wulf74, WulfSl], adds the observation 
that the abstraction mechanisms provided by the base model are not just for procedural, 
data, and control abstractions, but also for access abstractions, such as Redell's Caretaker. 
(These are "communications abstractions" in [Tribble95].) 

Access abstraction is pervasive in actual capability practice, including filtering facets, 
unprivileged transparent remote messaging systems [Donnelley76, Sansom86, Doorn96, 
MillerOO], reference monitors [Rajunas89], transfer, escrow, and trade of exclusive rights 
[Miller96, MillerOO], and recent patterns like thePowerbox [Wagner02, Stiegler02]. Fur- 
ther, every non-security-oriented abstraction that usefully encapsulates its internal state 
provides, in effect, restricted authority to affect that internal state, as mediated by the logic 
of the abstraction. 

The base system is also a security enforcing system, providing abstractions for control- 
ling access. When all code is either trusted or untrusted, one can only extend the expres- 
siveness of a protection system by adding code to the base, making everyone fully vulnera- 
ble to its possible misbehavior. By contrast, only Alice relies on the behavior of her Care- 
taker, and only to limit authority flowing between Bob and Carol. The risks to everyone, 
even Alice, from its misbehavior are limited because the Caretaker itself has limited au- 
thority. Alice can often bound her risk even from bugs in her own security enforcing pro- 
grams. 



5. Confinement 



... a program can create a controlled environment within which another, possi- 
bly untrustworthy program, can be run safely... call the first program a customer 
and the second a service. ... [the service] may leak, i.e. transmit ... the input 
data which the customer gives it. . . . We will call the problem of constraining a 
service [from leaking data ] the confinement problem. 

— Lampson [Lampson73] 

Once upon a time, in the days before wireless, you (a human customer) could buy a box 
containing a calculator (the service) from a manufacturer you might not trust. Although 
you might worry whether the calculations are correct, you can at least enter your financial 
data confident that the calculator cannot leak your secrets back to its manufacturer. How 
did the box solve the confinement problem? By letting you see that it comes with no 
strings attached. When the only causation to worry about would be carried by wires, the 
visible absence of wires emerging from the box — the isolation of the subgraph — is ade- 
quate evidence of confinement. 

Here, we use this same technique to achieve confinement, substituting capabilities for 
wires. The presentation here is a simplification of confinement in actual object-capability 
systems [Hardy86, Shapiro99, ShapiroOO, Wagner02, Yee03]. 

To solve confinement, assume that the manufacturer, Max, and customer, Cassie, have 
mutual access to a [Factory, factoryMaker] pair created by the following code. As- 
sume that Cassie trusts that this pair of objects behaves according to this code. 5 

def [Factory, factoryMaker] := { 

interface Factory guards FactoryStamp {...} 

def factoryMaker { 

to make (code : String) : Factory { 

A def factory implements FactoryStamp { 
to new (state) :any { 

A loader . load (code, state) 

} } } } 

[Factory, factoryMaker] 

} 

The interface .. guards expression evaluates to a (trademark guard, stamp) pair rep- 
resenting a new trademark, similar in purpose to an interface type. This syntax also de- 
fines variables to hold these objects, here named Factory and FactoryStamp. Here we 
use the FactoryStamp to mark instances of factory, and nothing else, as carrying this 
trademark. We use the Factory guard in soft type declarations, like ": Factory" above, 



5 Given mutual trust in this pair, our same logic solves an important mutual suspicion 
problem. Max knows Cassie cannot "open the case" — cannot examine or modify his 
code. 



to ensure that only objects carrying this trademark may pass. The block of code above 
evaluates to a [Factory, factoryMaker] pair. Only the factoryMaker of a pair can 
make objects, instances of factory, which will pass the Factory guard of that pair. 6 

Max uses a factoryMaker to package his proprietary calculator program in a box he 
sends to Cassie. 

def calculatorFactory := factoryMaker .make ("...code...") 
cassie . acceptProduct (calculatorFactory) 

In section 5.2 Cassie uses a ": Factory" declaration on the parameter of her accept- 
Product method to ensure that she receives only an instance of the above factory defini- 
tion. Inspection of the factory code shows that a factory's state contains only data (here, a 
String) and no capabilities — no access to the world outside itself. Cassie may therefore use 
the factory to make as many live calculators as she wants, confident that each calculator 
has only that access beyond itself that Cassie authorizes. They cannot even talk to each 
other unless Cassie allows them to. 

With lambda evaluation, a new subject's code and state both come from the same par- 
ent. To solve the confinement problem, we combine code from Max with state from Cassie 
to give birth to a new calculator, and we enable Cassie to verify that she is the only state- 
providing parent. This state is an example of Lampson's "controlled environment". To 
Cassie, the calculator is a controlled subject — one Cassie knows is born into an environ- 
ment controlled by her. By contrast, should Max introduce Cassie to an already instantiat- 
ed calculation service, Cassie would not be able to tell whether it has prior connectivity. 
(Extending our analogy, suppose Max offers the calculation service from his web site.) 
The calculation service would be an uncontrolled subject to her. 

We wish to reiterate that by "confinement", we refer to the overt subset of Lampson's 
problem, where the customer accepts only code ("a program") from the manufacturer and 
instantiates it in a controlled environment. We do not propose to confine information or 
authority given to uncontrolled subjects. 

5.1. A Non-Discretionary Model 

Capabilities are normally thought to be discretionary, and to be unable to enforce confine- 
ment. Our confinement logic above relies on the non-discretionary nature of object-capa- 
bilities. What does it mean for an access control system to be discretionary? 

"Our discussion ... rested on an unstated assumption: the principal that creates 
a file or other object in a computer system has unquestioned authority to autho- 
rize access to it by other principals. . . . We may characterize this control pattern 
as discretionary . " [emphasis in the original] 

— Saltzer and Schroeder [Saltzer75] 

6 Such trademarking can be implemented in DVH and in our model of object-capability 
computation [Morris73, Miller87, Tribble95, Rees96], so object-capability systems 
which provide trademarking primitively [Wulf81, Hardy85, Shapiro99, Yee03] are still 
within our model. 



Object-capability systems have no principals. A human user, together with his shell and 
"home directory" of references, participates, in effect, as just another subject. With the 
substitution of "subject" for "principal", we will use this classic definition of "discre- 
tionary". 

By this definition, object-capabilities are not discretionary. In our model, in DVH, and 
in most actual capability system implementations, even if Alice creates Carol, Alice may 
still only authorize Bob to access Carol if Alice has authority to access Bob. If capabilities 
were discretionary, they would indeed be unable to enforce confinement. To illustrate the 
power of confinement, we use it below to enforce the * -properties. 

5.2. The *-Properties 

Boebert made clear in [[Boebert84]] that an unmodified or classic capability 
system cannot enforce the ^-property or solve the confinement problem. 

—Gong [Gong89] 

Briefly, the * -properties taken together allow subjects with lower (such as "secret") 
clearance to communicate to subjects with higher (such as "top secret") clearance, but pro 
hibit communication in the reverse direction [Bell74]. KeySafe is a concrete and realistic 
design for enforcing the * -properties on KeyKOS, a pure object-capability system [Raju- 
nas89]. However, claims that capabilities cannot enforce the * -properties continue 
[Gong89, Kain87, Wallach97, Saraswat03], citing [Boebert84] as their support. Recently, 
referring to [Boebert84], Boebert writes: 

The paper . . . remains, no more than an offhand remark. . . . The historical signifi- 
cance of the paper is that it prompted the writing of [[Kain87]] 

—Boebert [Boebert03] 

Boebert here defers to Kain and Landwehr's paper [Kain87]. Regarding object-capabil- 
ity systems, Kain and Landwehr's paper makes essentially the same impossibility claims, 
which they support only by citing and summarizing Boebert. To lay this matter to rest, we 
show how Cassie solves Boebert's challenge problem — how she provides a one way com 
munication channel to subjects she doesn't trust, say Q and Bond, who she considers to 
have secret and top secret clearance respectively. Can Cassie prevent Boebert's attack, in 
which Q and Bond use the rights Cassie provides to build a reverse channel? 

Completing our earlier confinement example, Cassie accepts a calculator factory from 
Max using this method. 



to acceptProduct ( calcFactory :Factory) :void { 
var diode : int := 0 
def diodeWrlter { 

to write (val :int) :void { diode := val } 

} 

def diodeReader { 

to read() : int { A diode } 

} 

def q := calcFactory . new ([ "writeUp" => diodeWriter, ... ] ) 
def bond := calcFactory . new ( ["readDown" => diodeReader, ...] ) 

} 

Cassie creates two calculators to serve as Q and Bond. She builds a data diode by defin 
ing a diodeWriter, a diodeReader, and an assignable diode variable they share. She 
gives Q and Bond access to each other only through the data diode. Applied to Cassie's ar- 
rangement, Boebert's attack starts by observing that Q can send a capability as an argu 
ment in a message to the diodeWriter. An arrangement-only analysis of bounds on per- 
missions or authority supports Boebert's case — the data diode might introduce this argu- 
ment to Bond. Only by examining the behavior of the data diode can we see the tighter 
bounds it was built to enforce. It transmits data (here, integers) in only one direction and 
capabilities in neither. (Q cannot even read what he just wrote!) Cassie relies on the be- 
havior of the factory and data diode abstractions to enforce the * -properties and prevent 
Boebert's attack. (See [Miller03] for further detail.) 

5.3. The Arena and Terms of Entry 

Policies like the * -properties are generally assumed to govern a computer system as a 
whole, to be enforced in collaboration with a human sys-admin or security officer. In a ca- 
pability system, this is a matter of initial conditions. If the owner of the system wishes 
such a policy to govern the entire system, she can run such code when the system is first 
generated, and when new users join. But what happens after the big bang? Let's say Alice 
meets Bob, who is an uncontrolled subject to her. Alice can still enforce "additive" poli- 
cies on Bob, e.g., she can give him revocable access to Carol, and then revoke it. But she 
cannot enforce a policy on Bob that requires removing prior rights from Bob, for that 
would violate Bob's security! 

Instead, as we see in the example above, acting as Lampson's "customer", she sets up 
an arena — Lampson's "controlled environment" — with initial conditions she determines, 
governed by her rules, and over which she is the sys-admin. If her rules can be enforced on 
uncontrolled subjects, she can admit Bob onto her arena as a player. If her rules require 
the players not to have some rights, she must set terms of entry. "Please leave your cell- 
phones at the door." A prospective participant (Max) provides a player (calcFactory) to 
represent his interests within the arena, where this player can pass the security check at the 



gate (here, : Factory). No rights were taken away from anyone; participation was volun- 
tary. 

The arena technique corresponds to meta-linguistic abstraction — an arena is a virtual 
machine built within a virtual machine [Abelson86, Safra86]. The resulting system can be 
described according to either level of abstraction — by the rules of the base level object-ca- 
pability system or by the rules of the arena. The subjects built by the admitted factories are 
also subjects within the arena. At the base level, we would say Q has permission to send 
messages to diodeWriter and authority to send integers to Bond. At the arena level of 
description, we would say a data diode is a primitive part of the arena's protection state, 
and say Q has permission to send integers to Bond. Any base level uncontrolled subjects 
admitted into the arena are devices of the arena — they have mysterious connections to the 
arena's external world. 

When the only inputs to a problem are data (here, code), any system capable of univer- 
sal computation can solve any solvable problem, so questions of absolute possibility be- 
come useless for comparisons. Conventional language comparisons face the same dilem- 
ma, and language designers have learned to ask instead an engineering question: Is this a 
good machine on which to build other machines? How well did we do on Boebert's chal- 
lenge? The code admitted was neither inspected nor transformed. Each arena level subject 
was also a base level subject. The behavior interposed byCassie between the subjects was 
very thin. Mostly, we reused the security properties of the base level object-capability sys- 
tem to build the security properties of our new arena level machine. 

5.4. Mutually Suspicious Composition 

When mutually suspicious interests build a diversity of abstractions to express a diversity 
of co-existing policies, how do these extensions interact? 

Let's say that Q builds a gizmo that might have bugs, so Q creates a Caretaker to give 
the gizmo revocable access to his diodeWriter. Q's policy relies on the behavior of his 
Caretaker but not necessarily on Cassie's diodeWriter. To Cassie, Q's gizmo and Care- 
taker are part of Q's subgraph and indistinguishable from Q. Cassie's policy relies on the 
behavior of her diodeWriter, but not on Q's Caretaker. They each do a partially behav- 
ioral analysis over the same graph, each from their own subjective perspective. This sce- 
nario shows how diverse expressions of policy often compose correctly even when none of 
the interested parties are aware this is happening. 

6. Conclusion 

Just as we should not expect a base programming language to provide us all the data types 
we need for computation, we should not expect a base access control system to provide us 
all the elements we need to express our protection policies. Both issues deserve the same 
kind of answer: We use the base to build abstractions, extending the vocabulary we use to 
express our solutions. In evaluating a protection model, one must examine how well it sup 
ports the extension of its own expressiveness by abstraction and composition 



Security in computational systems emerges from the interaction between primitive pro- 
tection mechanisms and the behavior of security enforcing programs. As we have shown 
here, such programs are able to enforce restrictions on more general, untrusted programs 
by building on and abstracting more primitive protection mechanisms. To our knowledge, 
the object-capability model is the only protection model whose semantics can be readily 
expressed in programming language terms: approximately, lambda calculus with local side 
effects. This provides the necessary common semantic framework for reasoning about per- 
mission and program behavior together. Because security-enforcing programs are often 
simple, the required program analysis should frequently prove tractable,/?rov/(ieaf they are 
built on effective primitives. 

By recognizing that program behavior can contribute towards access control, a lost 
paradigm for protection — abstraction — is restored to us, and a semantic basis for extensi- 
ble protection is established. Diverse interests can each build abstractions to express their 
policies regarding new object types, new applications, new requirements, and each other, 
and these policies can co-exist and interact. This extensibility is well outside the scope of 
traditional access graph analyses. 

Analyses based on the evolution of protection state are conservative approximations. A 
successful verification demonstrating the enforcement of a policy using only the protection 
graph (as in [ShapiroOO]) is robust, in the sense that it does not rely on the cooperative be- 
havior of programs. Verification/ai'/wrei are not robust - they may indicate a failure in the 
protection model, but they can also result from what might be called "failures of conser- 
vatism" — failures in which the policy is enforceable but the verification model has been 
simplified in a way that prevents successful verification. 

We have shown by example how object-capability practitioners set tight bounds on au- 
thority by building abstractions and reasoning about their behavior, using conceptual tools 
similar to that used by object programmers to reason about any abstraction. We have 
shown, using only techniques easily implementable in Dennis and van Horn's 1966 Super- 
visor, how actual object-capability systems have used abstraction to solve problems that 
analyses using only protection state have "proven" impossible for capabilities. 

The object-capability paradigm, with its pervasive, fine-grained, and extensible support 
for the principle of least authority, enables mutually suspicious interests to cooperate more 
intimately while being less vulnerable to each other. When more cooperation may be prac- 
ticed with less vulnerability, we may find we have a more cooperative world. 
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